D,Rough requirements,Requirement analysis,Defined goals for project,Project is not of limited scope,manager role,Agile development,Clear team member responsibilities,Verifiable requirements,self-imposed deadline,Digital Kanban,Test Driven Development,Lean Developoment,Hack-and-Plan,Trello downsides,Access to end-user,Access to outside expertise,Application expertise within team,Team-building to increase effectiveness,Co-location reduces need for organized communication,Version control as documentation tool,High level task definition due to chaotic context,Version control,Google Ventures Design Sprints,Priority on product quality versus speed of delivery ,Iterative development,Priority pon speed of delivery versus product quality,Organized coding practices,Behaviour Driven Development,Priority on user experience in testing,Interfaces specified and tested manually,Adaptable work procedures,Low architectural uncertainty,72,59,31,Proper tools,Always start with the simplest implementation – Stupid simple fast 3 guiding principles,Single person responsible for management of startup,Prototype requirements include solution setup by third party,Important to dedicate minimal to no investments in long term projects with no demonstrable early results in a startup’s early phase,Issues defined to the level felt appropriate with respect to uncertainty,Modified Google Ventures Design Sprints used for project management,Speed a deciding factor for choice of development environment,Clear division of responsibilities within development team,Startup had a vision statement ready before starting prototype development,Tasks initially defined as fitting for each task due to information not available until starting task,The team sometimes reserved a day to resolve a specific issue,Team put priority on proper tools and work methods rather than cheap or quick ones (due to existing proficiencies),Founding team includes member with application area expertise.,Kanban task management rather than extreme programming,Accelerator participation main weakness of prototype development work methodology by reducing available time for development,Team should focus on developing a scalable and maintainable software because those issues are harder to solve than acquiring more computing power when a user capacity is reached,Assuredness of key user demographic prior to prototype development,Product visual designer availability from day 1 big part in success,Founding team had access to an advisory council – have been helpful filling team knowledge gaps and providing management advice,Team intended to use first prototype to find a scalable architecture in addition to usability development,Close acquaintances for user testing of prototype,No task size estimations,Development somewhat based on Agile methodologies,Sit-down discussions for problem solving,Prototype was source controlled,API specification evolution trackable in source control,No integration tests in prototype,Optimization of nonexistent product is waste,Dynamic work methodology,Frequent user tests,Did not use BDD due to time constraints,APIs documented with strict specifications,Startup had easy access to an example end-user,Initial development required some rework due to lack of oversight by senior developer and some unclear task definitions,Declared if not well-defined functional and non-functional needs for prototype,Priority on working together,Minimal or no documentation of work procedures.,Founder is a proponent of organized work even in startups,Team prioritized certain features of the prototype,Architecture designed by a single person,Lessons learnt: Founder would have wanted more decisiveness in his leadership,Negative experience of backend as a service,User tests very design and UX oriented,Some functionality defined in terms of BDD,Lessons learnt: Better organization of documents could have saved a lot of aggregate document look up time,Hack-and-plan a good tool for startup management of the various projects/tasks performed in a startup,Co-location of a small <=5 person team enables constant communication,Founder places great importance on active communication especially on problems,Hack-and-plan,Trello too simple for the variance of startup projects/tasks,Iterative prototype development with iterations based on minified Google Ventures Design Sprints,Team performed a requirement analysis for prototype,Modified stand-up meetings,Prototype intended to verify implementation solutions for issues for more than one user profile,Test Driven Development,Weekly team-building events used for open discussion,Lessons learnt: Founder would have wanted to have defined the underlying problem better,Organized work methodology led to well defined goals,Document change history visible in source control,Team decided on a self-defined/imposed time limit on opportunity exploration/prototype development,Not a throw away prototype,Focus on and time invested in the agility and adaptability of development work,Ticket system to track tasks and activities,Pseudo-familial bond within founding team members.,Startup got positive feedback for an early prototype,Goals and questions for prototype set prior to start of development,Development Environment main architectural unknown for prototype,Team felt kanban to be a better management tool to tackle the constant adjustment of the startups first steps,Team focused on prototyping the most critical component of the intended solution,Prototype also tests technical hypotheses scalability in particular,Coding Standards to homogenize code from different developers,Team‘s dynamic work methods lead to quick work
